Although several possibilities for making subsequent changes or modifications to software are known from the prior art, they all have a number of disadvantages:
One possibility of influencing software is realized with the aid of parameterization. Configuration files are typically used for parameterization and storage of application-specific “parameter data”. The structure and format of the files are defined during the development phase and are in no way modifiable once the software has been shipped.
Plug-ins open up the possibility of extending already “shipped”, compiled software with functionality characteristics. Toward that end it is necessary that the structures for integrating and using plug-ins are already implemented or specified during the development phase (interfaces, . . . ).
Code generators generate source or binary code with the aid of templates which are completed at predetermined points, for example by use of parameters that have been passed. In this way it becomes possible to generate different software for different customers for example, the software differing at precisely defined points. In this case, however, only special points (and not arbitrary points) in the code can be modified, which points must be specified precisely when the template is produced. Code generators are typically used on the developer side.
A special application possibility of using variation points in the form of updates/patches is known from U.S. Pat. No. 6,052,531A1.
A Java source code transformation tool called BeautyJ is known from the internet at http://beautyj.berlios.de/, wherein a Java source code is converted into an XML representation, “beautified” using Sourclet API, for example by insertion of white spaces or modified comments at specific points, and subsequently the modified source code can be converted back into Java source code. A transformation by way of XSLT is only proposed here, for this purpose, but not implemented.